\section{Diagrammes de classes}
\label{classes}
Les diagrammes de classes constituent lors de l'étape de conception une définition formelle des objets qui composent notre programme.
Nous les avons construit en parallèle des autres diagrammes : en effet, les diagrammes de classes constituent une base conceptuelle pour les autres diagrammes, mais il est difficile de ne rien oublier si l'on travaille uniquement sur des diagrammes statiques. 

Nous avons réalisé deux diagrammes de classes : le diagramme des interfaces et le diagramme d'implémentation. 
Ces diagrammes vont nous permettre de générer le squelette de notre programme. Il est donc nécessaire de s'assurer qu'ils soient non seulement complets, mais qu'ils respectent également certains patrons de conceptions. Ils permettent d'avoir une solution générique et éprouvée à différents problèmes que l'on va rencontrer lors du codage de ce programme.

\subsection{Diagramme des interfaces}(cf. figure \ref{interfaces})
Le diagramme des interfaces permet d'exhiber la structure de notre programme, tout en garantissant des facilités de maintenance si une partie de l'implémentation venait à changer. 

\begin{figure}[!ht]
	\centering
	\includegraphics[width=\textwidth]{./Images/interfaces.png}
	\caption{Diagramme des interfaces}
		\label{interfaces}
	Version agrandie : Diagramme de classes (interfaces).pdf
\end{figure}


L'interface Jeu est la classe qui se charge de mettre en relation les différents éléments de notre programme.

L'interface Joueur est instanciée une fois par joueur et permet notamment d'accéder aux unités d'un joueur.

L'interface Unité est une interface générique pour les différents types d'unités qui seront présentes dans le jeu. Chaque type d'unité possède une interface dédiée (Etudiant, Enseignant, Directeur de département).

L'interface Carte permet d'associer des Cases et des listes d'unités présentes à des coordonnées (représentées par deux entiers X et Y).

Les interfaces Case et Ville permettent de montrer tous les éléments nécessaires pour qu'une implémentation de ces éléments réponde au cahier des charges.

\paragraph{Un premier patron de conception : la fabrique abstraite}(cf. figure \ref{fabrique})
La fabrique abstraite permet de fournir une interface pour la création des unités sans pour autant spécifier les classes concrètes : on peut donc faire cohabiter deux implémentations, que nous verrons dans le prochain diagramme : FabriqueEii et FabriqueInfo.

\begin{figure}[!ht]
	\centering
	\includegraphics[width=\textwidth]{./Images/fabrique_abstraite.png}
	\caption{Diagramme des interfaces}
		\label{fabrique}
\end{figure}


\subsection{Diagramme de classes}
Le diagramme d'implémentation montre l'implémentation concrète de nos interfaces, et la manière dont sont résolus un certain nombre de problèmes via les patrons de conception.

Le diagramme d'implémentation complet est disponible dans le fichier "diagramme de classe (implémentation).pdf", nous ne détaillons dans ce rapport que les patrons de conceptions.

\paragraph{Le patron de conception Monteur}(cf. figure \ref{monteur})
Le patron Monteur permet de séparer la construction des différents éléments d'une même partie (via une classe implémentant un Monteur abstrait) de leur représentation en mémoire (les classes correspondantes, telles que Ville, Joueur ...). En effet, il est envisageable de proposer plusieurs façon de créer une nouvelle partie et il n'est pas adapté de coder ces options directement dans les classes du modèle.
Dans notre programme, nous ne proposerons dans un premier temps qu'une seule manière de créer le jeu via la classe MonteurJeu.
\paragraph{Le patron de conception Stratégie}(cf. figure \ref{monteur})
Le patron Stratégie permet de changer d'implémentation pendant l'exécution : si on définit plusieurs manières de créer la carte, on doit pouvoir choisir l'une ou l'autre suivant le choix de l'utilisateur sans avoir à recompiler le programme.

\begin{figure}[!ht]
	\centering
	\includegraphics[width=0.5\textwidth]{./Images/monteur.png}
	\caption{Patrons de conception Monteur et Stratégie}
		\label{monteur}
\end{figure}

\paragraph{Les patrons Poids-mouche et Décorateur}(cf. figure \ref{decorateur})
Ces deux patrons permettent de diminuer la consommation mémoire des instances des cases.

Le patron décorateur permet d'éviter de créer des classes pour toutes les combinaisons de terrain (désert, montagne et plaine) et de ressources (fruit et fer). Ainsi, pour créer un désert simple, on instancie de manière classique la classe Desert. Pour créer un désert avec du fer, on instancie DecorateurFer en lui donnant comme attribut Terrain un pointeur vers une instance de Desert. On a donc ici 5 classes différentes, au lieu de coder les 9 combinaisons possibles.

Le patron poids-mouche permet d'éviter d'instancier plusieurs fois des objets strictement identiques : la fabrique de case créera un nouvel objet si la combinaison demandée n'existe pas encore, ou renverra un pointeur vers l'objet instancié correspondant dans le cas contraire. On instanciera ainsi au plus les 9 combinaisons possibles, quelle que soit la taille de la map.

\begin{figure}[!ht]
	\centering
	\includegraphics[width=\textwidth]{./Images/cases.png}
	\caption{Patrons de conception Poids-mouche et Décorateur}
			\label{decorateur}
\end{figure}